我該強迫其他人一起寫測試嗎？

如果你已經在你的專案上面加上了測試，我想信你也很希望團隊裡的其他人跟你一起寫測試，尤其是如果你體會到測試帶給你的好處後，你甚至會想強迫他們一起寫。

但千萬不樣這樣做，因為你經過了一段時間的努力，你已經會寫一些測試了，但是他們還不會，他們還沒體會到測試的好處，現在逼他們寫效果不好，有時我們需要讓子彈飛一下。

讓子彈飛一下

你應該體會到有了測試保護後，你 Debug 的時間應該變少了。

修改程式時，有測試保護的功能，如果不小心被改壞了，幾乎都能在第一時間發現，減少了改 A 壞 B 的機率。

這是一個正向的循環，會讓你會更想寫測試。現在你需要的就是等待，等待東風吹起。

其他基礎建設

在等待的時候我們可以先把一些基礎建設弄好。

例如，程式碼一定要有 source control (e.g. git)，沒有的話，就要想辦法說服大家一定要有。

有了 source control 後，就要建立 CI (Continuous Integration， 持續整合)。建立 CI 的目的是讓你的測試能夠發揮更大的作用。

在這裡我們希望 CI 能在每次有人 commit code 時，自動幫我跑測試。 CI 有很多的優點和功能，有興趣可以看一下其他鐵人的文章，我相信一定很多。這邊我們只是簡單的帶過一些東西。

至於 CD (Continuous Delivery，持續交付) 也有很大的功用，但在這裡我們先不用做，你的團隊原本怎麼交付你的軟體，現在就還是為持原樣就好了。

改動應該讓他人無感

現在我們回頭來看一下我們的改動

• 1 - 專案加了一些測試
• 2 - 建立了一台 CI
• 3 - 在每次有人 commit code 時， CI 自動幫我們跑測試

我們來看看我們所做的這些事情對其他人是否有影響？

1 - 專案加了一些測試

測試的部分，他們在自己的電腦上跑不跑測試對他們來說沒有差別，只要能 Build 的過，我想大家都不會有意見。

2 - 建立了一台 CI

CI 是你花時間建立的，也沒有要求他們要多做些什麼，他們應該無視。

3 - 在每次有人 commit code 時， CI 自動幫我們跑測試

CI 他們都無視了，我想 CI 上做些什麼他們也都不會管。這裡我們並沒有要在 Build fail 或 Test fail 時，發警告去煩他們。所以不會有人注意到這個的。

萬事俱備，只欠東風

但你不一樣，你在等的就是 Build fail 或 Test fail， 這就是東風來了，我們明天再繼續。